Add a new wasm32-wasip3 target to Rust
#147205
Conversation
|
Some changes occurred in src/doc/rustc/src/platform-support cc @Noratrieb These commits modify compiler targets. |
rustbot
added
S-waiting-on-review
rustbot
added
T-compiler
|
I'll also note that this target won't build until rust-lang/libc#4733 is included as well. Additionally, following the guidelines here ... r? compiler_leads |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Question (somewhat off-topic): what are the long term plans for the wasm32-wasip* set of targets? Or are the WASIpN more like "profiles" in terms of which WASI APIs are available?
There was a problem hiding this comment.
I wouldn't say that the WASI targets are quite like profiles. For today's meeting between T-Lang and the Wasmtime team (unrelated to this PR), Alex wrote the following about the WASI versions. I thought it was really good, so I'll paste it here in full:
Appendix C: WASI Versions
To expand on the glossary terms above:
- WASIp1 - no longer in development. Completely unrelated to the component model. Completely custom ABI and type system used to define APIs, and most APIs looked more-or-less like a C signature.
- WASIp2 - first release of WASI "rebased" on the Component Model. All APIs defined in terms of WIT using component model types (e.g.
record,string, etc). Functionality-wise WASIp2 is a superset of WASIp1 and notably includes support for TCP/UDP sockets. This more-or-less conicided with the first "release" of the component model itself, although the component model doesn't have an official release cadence. In lieu of that WASI versions have been used to introduce component model features. Regardless this is why Rust'swasm32-wasip2target, for example, produces a component instead of a core module as output.- WASIp3 - next in-development version of WASI, not currently released/stamped. Major feature over WASIp2 is native async support in the component model itself, reflected in WIT as
asyncfunctions for example. Additionally there are two new types in WIT,future<T>andstream<T>. Functionality remains the same as WASIp2 except that doing async operations is "much nicer" in terms of how languages integrate. Semantically it's now possible to invoke concurrent computations within a single component if it's exported as anasyncfunction in WIT.Notably WASIp1 is incompatible with WASIp{2,3} due to how its APIs are defined. The core-level ABI and types of WASIp1 are incompatible with the component model and WASIp{2,3}. For WASIp{2,3}, however, the underyling format is "just a component" which means that a component can simultaneously import, and export WASIp2 and WASIp3 APIs. This means that all development of WASIp3-as-a-standard has been using the
wasm32-wasip2Rust target, for example. WASIp3 does not mean that WASIp2 is gone and inaccessible, but rather WASIp3 means that there's access to more functions. Idiomatically a true WASIp3 target wouldn't use WASIp2 at all, and that's the end goal, but this is not a requirement in the transition period from WASIp2 to WASIp3.
The plan is to eventually drive WASI to a 1.0 status, at which point we'll be able to drop the "preview" suffix. From a maintenance perspective WASIp2, WASIp3, and the eventual WASI 1.0 will share most of their infrastructure in the compiler, with most of the differences being in the stdlib. This should make them relatively easy to maintain as a set. This is different for WASI 0.1, which is different enough from the other targets that it needs to be maintained as its own target.
There was a problem hiding this comment.
Okay, that makes sense and is helpful context. Thanks.
This comment has been minimized.
This comment has been minimized.
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group. As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a more-ready-than-nonexistent state by the time this happens in December. For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably: * The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup. * Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use. * Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target. These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change. [`wasip3` crate]: https://crates.io/crates/wasip3
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
There was a problem hiding this comment.
LGTM, but just to follow procedure, can you go over the points in the Tier 3 target tier policy (like in the description of #146848)
|
Certainly!
That'll be me for now
This is matching the naming/functionality precedent of
Building/using
Sounds good.
The libstd support of
I've attempted to write down what I know in
This new target won't be any more of a burden than
Any breakage here would definitely be unintentional and I'm happy to follow-up with a fix if that happens.
The wasm backend in LLVM is sufficient for this. |
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
Add a new `wasm32-wasip3` target to Rust This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group. As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a more-ready-than-nonexistent state by the time this happens in December. For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably: * The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup. * Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use. * Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target. These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change. [`wasip3` crate]: https://crates.io/crates/wasip3
Rollup of 8 pull requests Successful merges: - #145608 (Prevent downstream `impl DerefMut for Pin<LocalType>`) - #146865 (kcfi: only reify trait methods when dyn-compatible) - #147205 (Add a new `wasm32-wasip3` target to Rust) - #147390 (Use globals instead of metadata for std::autodiff) - #147398 (Fix; correct placement of type inference error for method calls) - #147422 (collect-license-metadata: Print a diff of the expected output) - #147431 (compiletest: Read the whole test file before parsing directives) - #147433 (Fix doc comment) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 8 pull requests Successful merges: - #145608 (Prevent downstream `impl DerefMut for Pin<LocalType>`) - #146865 (kcfi: only reify trait methods when dyn-compatible) - #147205 (Add a new `wasm32-wasip3` target to Rust) - #147390 (Use globals instead of metadata for std::autodiff) - #147398 (Fix; correct placement of type inference error for method calls) - #147422 (collect-license-metadata: Print a diff of the expected output) - #147431 (compiletest: Read the whole test file before parsing directives) - #147433 (Fix doc comment) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 8 pull requests Successful merges: - #146865 (kcfi: only reify trait methods when dyn-compatible) - #147205 (Add a new `wasm32-wasip3` target to Rust) - #147322 (cg_llvm: Consistently import `llvm::Type` and `llvm::Value`) - #147398 (Fix; correct placement of type inference error for method calls) - #147410 (Update `S-waiting-on-team` refs to new `S-waiting-on-{team}` labels) - #147422 (collect-license-metadata: Print a diff of the expected output) - #147431 (compiletest: Read the whole test file before parsing directives) - #147433 (Fix doc comment) Failed merges: - #147390 (Use globals instead of metadata for std::autodiff) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #147205 - alexcrichton:wasip3, r=davidtwco Add a new `wasm32-wasip3` target to Rust This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group. As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a more-ready-than-nonexistent state by the time this happens in December. For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably: * The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup. * Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use. * Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target. These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change. [`wasip3` crate]: https://crates.io/crates/wasip3
Add a new `wasm32-wasip3` target to Rust This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group. As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a more-ready-than-nonexistent state by the time this happens in December. For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably: * The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup. * Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use. * Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target. These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change. [`wasip3` crate]: https://crates.io/crates/wasip3
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#146865 (kcfi: only reify trait methods when dyn-compatible) - rust-lang#147205 (Add a new `wasm32-wasip3` target to Rust) - rust-lang#147322 (cg_llvm: Consistently import `llvm::Type` and `llvm::Value`) - rust-lang#147398 (Fix; correct placement of type inference error for method calls) - rust-lang#147410 (Update `S-waiting-on-team` refs to new `S-waiting-on-{team}` labels) - rust-lang#147422 (collect-license-metadata: Print a diff of the expected output) - rust-lang#147431 (compiletest: Read the whole test file before parsing directives) - rust-lang#147433 (Fix doc comment) Failed merges: - rust-lang#147390 (Use globals instead of metadata for std::autodiff) r? `@ghost` `@rustbot` modify labels: rollup
This commit adds a new tier 3 target to rustc,
wasm32-wasip3. This follows in the footsteps of the previouswasm32-wasip2target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group.As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a
more-ready-than-nonexistent state by the time this happens in December.
For now the
wasm32-wasip3target looks exactly the same aswasm32-wasip2except thattarget_env = "p3"is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as thewasip3crate. Over time this target will evolve as implementation in guest toolchains progress, notably:wasi-libcwill be updated to use WASIp3 natively which Rust will then transitively use.std::thread, for example, on this target.These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change.